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DATA PROCESSING 



FIELD OF THE INVENTION 

5 

The present invention concerns a method for data sharing between companies of similar 
organisations where multiple payments flow between them. 

The invention will be described with particular reference to the vehicle insurance field, 
1 0 but those skilled in the art will see the applicability to fields with similar activity, namely 
software providers, data matchers and trading exchanges such as stock exchanges. 

BACKGROUND OF THE INVENTION 

15 The interaction between insurance companies, factors, policy holders, repairers and 
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claimants is complex. Much of the work of claims departments is paper based. 
Transposing clerical errors causes delays in payment. Most of the companies have 
idiosyncratic processing features, many of which act as a rate determining step or an 
outright barrier to prompt payments. Simplification arrived when "knock for knock" 
5 became acceptable to the industry but this could not deal with all categories of business 
and is being gradually disbanded. ^ 

Accordingly companies inherit legacies of in-house data generation and data handling, 
but the penalty for having them is slow interfacing with outside companies and much 

10 needless human intervention results before payment is made and the claim file is closed. 
Companies continue to require claims departments which are costly to run. While about 
30% of vehicle accidents are straight forward in that they are rear end collisions where 
there is no dispute even between two insurers, the remainder of the claims are more 
complex and defy rationalisation into a system which all the parties would trust and then 

1 5 adopt. 

SUMMARY OF THE INVENTION 

One aspect of this invention provides a business method of creating compatibility of data 
20 exchange between multiple parties, utilising disparate data in disparate formats 
contributed by the parties, placing the data in a common repository wherein the data is 
processed to permit automated treatment of data between the parties. 

Assuming each party has a legacy system of data handling, the method comprises 
25 uploading Essential Data from the legacy systems of the parties to a common processing 
system, matching the Essential Data in that common processing system and notifying the 
parties of a match/non-match status. 

Preferably the notification is accompanied by the Essential Data. The parties who 
30 contribute claims data are the insurers and therefore they receive the match/no-match 
advice and it is immediately apparent that the two companies are referring to the same 
accident and the companies can progress to the next stage of the claim. 
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Preferably the uploading is preceded by conversion of the legacy data to a compatible 
data for the common processing step via software which translates the legacy data of the 
insurers into a common compatible language. Extensible Mark Up Language is an 
example of such translating standard. The establishment of a match may be 
5 automatically notified to the insurers. Preferably the notification is accompanied by 
Essential Data via the same channel which omitted the data from the insurer. 

The virtue of the method above lies in that the common format procedure for the 
disparate data allows for example a traffic incident reported to insurer A is recognised by 
1 0 insurer B as relational to the said traffic incident reported and coded by them in different 
ways. 

The translation stage may include the imposition of a set of codes to render information 
to each insurer. The codes may be industry standards. The codes may be Relational 
1 5 Incident codes. 

Specifically insurer A's incident is hitting a vehicle in the rear. Insurer B's incident is 
a vehicle suffering a hit in the rear. Making the codes relational allows legacy terms such 
as HIR (hit in rear) and DAF (driver at fault) to be codified to express one incident as the 

20 mirror image of the other allowing the claim to flow to the next step. Thus a traffic 
incident reported to insurer A is recognised by insurer B as relational to the incident 
reported and coded by him in a different way. It may be that not all insurers provide 
legacy code which lends itself to translation into common format in all instances. There 
may be a prior screening step during which the legacy code is inspected for suitability 

25 and sufficiency, eg. needing to specify the point of impact on the vehicle (front, mid or 
rear). 

The match may lead to a settlement decision by the "at fault" insurer. This decision will 
be subject to Proof of Loss and may be manual or electronic according to insurer 
30 selectable parameters. Thereafter either the Settlement Authority or a Request for 
Further Information - Denial may be generated by the "at fault" insurer. 

If accepted the common processing system has automatically settled the claim. 
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Alternatively if the "at fault" insurer by prior inclusion of parameters, may instruct the 
common processing system by translation back into the insurers legacy system the 
information supplied by the "not at fault" insurers Essential Data. 

5 The "at fault" insurer may then make a manual assessment of the incident by inspecting 
incidental data especially estimated repair costs. ~" 

The end of the chain of common processing of the incident which created the claim may 
be a End-of-Day settlement of all accounts between a pair of insurers. A nett daily 
10 balance may be paid from a settlement float, for example a Claims Reserve. 

In our co-pending patent application No. , we describe a method of processing 

claims by core method steps which allows notice to be taken of non-standard preferences 
and idiosyncrasies of procedure which exist among the businesses forming part of the 
1 5 repair chain. This permits data pertaining to the claims to be accessible to the parties for 
allowing updating and revision. 

In the simplest form, the invention provides a data matching method for vehicle 
insurance claims, comprising comparing data concerning vehicle incidents involving two 
20 vehicles, namely the registration numbers of the vehicles, the date of the incident and the 
individual claim numbers given by the insurers to the incident, and seeking a match in 
order to indicate that two sets of data refer to the same incident. 

Preferably, the data includes the insurers category which classifies the type of incident. 
25 ■ * 

BRIEF DESCRIPTION OF THE VIEWS OF THE DRAWINGS 

Examples of the method are now described with reference to the accompanying 
drawings:- 

30 

Figure 1 shows the prior art scheme; 

Figure 2 shows all the parties in Figure 1 donating and accepting data to and from 
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the common processor; 

Figure 3 is a diagram showing the translation of data to insurers to mutually 
compatible form ready for matching; and 

5 

Figure 4 is a diagram of Essential Data ready for~order automatic claim 
settlement. 

Figure 5 is a flow diagram fro an insurance claim. 

10 

DETAILED DESCRIPTION WITH RESPECT TO THE DRAWINGS 

The existing scheme is seen in Figure 1. A single vehicle accident procedure is as 
follows:- 

15 

A claim is lodged with an insurer, who captures certain essential pieces of information 
into their existing 'legacy* computer system. This information would identify, at a 
minimum:- 

20 The insurer's internal unique claim number; 

The registration number of their insured's vehicle; 
The registration number of any other vehicle involved; 
The date of incident; 

The insurer's internal coding describing the type of incident; 
25 An indication of the liability of the insurer; and 

The cost of repairing their insured's vehicle. 

Similarly, the second insurer would identify via their internal computer 'legacy' system 
the above information; however the format and content of certain information will most 
30 likely differ due to internal implementation of their systems, for example:- 

The insurer's internal unique claim number; 

The insurer's internal coding describing the type of incident; and 
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An indication of the liability of the insurer. 

However, whilst this information may be of different format and content, the information 
is related, as they are both records of the same motor vehicle incident albeit from the 
5 perspective of their own insured's involvement in the incident. 

Also, certain information will be almost identical in content (although the specific format 
as recorded in each insurer's computer 'legacy' system may differ), ie. same content, 
different format, for example:- 

10 

The registration number of their insured's vehicle; 

The registration number of any other vehicle involved; and 

The date of incident. 

1 5 The method exploits these two critical sets of characteristics in order to largely automate 
a previously manual set of business processes describing the relationship between these 
two insurers (as described in Figures 2 and 3) as follows:- 

The method supplies a set of standards (in an industry-standard format, eg. XML) for the 
20 description of the format of both sets of data, to each participating insurer. Each 
participating insurer then develops a simple translation routine to convert the 
aforementioned data items into the standard Essential Data (ie. in XML format) (see 
Figure 3). 

25 The Essential Data will contain, at a minimum: 

The insurer's internal unique claim number; 
The registration number of their insured's vehicle; 
The registration number of any other vehicle involved; 
30 The date of incident; 

The insurer's internal coding describing the type of incident; and 
An indication of the liability of the insurer. 
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Whilst the content of some data items may still be unique, the format will now be 
identical, for example:- 

The insurer's internal unique claim number. 

In addition, the method, as part of this translation process, supplies an industry standard 
set of codes (ie. Relational Incident Codes) to describe information previously of an 
incompatible form to each insurer, for example:- 

The insurer's internal coding describing the type of incident; and 
An indication of the liability of the insurer. 

When two vehicles are involved the paper flow increases to include the following steps- 
Preliminary letter of demand 
Correspondence to insurer 
Company to company advice 
Proof of loss to "Insurer B : 
Settlement to "Insurer A" 

It is also part of the method's translation process that these common pieces of 
information are now readily shown to relate to the same incident, albeit from the 
perspective of the insurer of each vehicle according to the information reported to them 
by the owner of the vehicle. 

The method has effectively converted information supplied by each insurer of different 
content and different format into the Essential Data now of identical format and identical 
content. 

Therefore, the method, now has generated in standard format as a result of this translation 
process, identical information in terms of content and format (provided that each piece 
of information was reported correctly by the owner of each vehicle to each insurer), for 
example:- 
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The registration number of their insured's vehicle; 

The registration number of any other vehicle involved; and 

The date of incident. 

5 Once this information has been translated by each insurer into the method Essential Data 
according to the method's unique translation standards, the~lhformation is randomly 
transmitted (in time) by each insurer to the central the method hub where it is randomly 
stored in the Method Hub's Database. 

10 In the Hub's Database exists a Data Matching system that is now able to examine each 
Essential Data group as it is transmitted and stored, and compare each group already 
stored in the current part of the Database. 

When the method is used in a trading exchange the commodities may be known by 
1 5 regional names. These are translated into a common language eg. a plant or crop name 
may be converted to a botanical name. This together with an offering price and a supply 
date would constitute the Essential data. Claims for medical attention and worker's 
compensation lend themselves to similar treatment. 

20 Procedure using the Invention 

A claim is lodged with an insurer, who captures certain essential pieces of information 
into their existing 'legacy' computer system. This information would identify, at a 
minimum: 

25 

The insurer's internal unique claim number; 
The registration number of their insured's vehicle; 
The registration number of any other vehicle involved; 
The date of incident; 
30 The insurer's internal coding describing the type of incident; 

An indication of the liability of the insurer; and 
The cost of repairing their insured's vehicle. 
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Similarly, the second insurer would identify via their internal computer 'legacy' system 
the above information; however the format and content of certain information will most 
likely differ due to internal implementation of their systems, for example:- 

5 The insurer's internal unique claim number; 

The insurer's internal coding describing the type of iriefdent; and 
An indication of the liability of the insurer. 

However, whilst this information may be of different format and content, the information 
10 is related, as they are both records of the same motor vehicle incident albeit from the 
perspective of their own insured's involvement in the incident. 

Also, certain information will be almost identical in content (although the specific format 
as recorded in each insurer's computer 'legacy' system may differ), ie. same content, 
1 5 different format, for example:- 

The registration number of their insured's vehicle; 

The registration number of any other vehicle involved; and 

The date of incident. 

20 

The method exploits these two critical sets of characteristics in order to largely automate 
a previously manual set of business processes describing the relationship between these 
two insurers (as described in diagrams 2 and 3) as follows:- 

25 The method supplies a set of standards (in an industry-standard format, eg. XML) for the 
description of the format of both sets of data, to each participating insurer. Each 
participating insurer then develops a simple translation routine to convert the 
aforementioned data items into the method-standard Essential Data (ie. in XML format) 
(see Figure 3). 

30 

The method's Essential Data will contain, at a minimum: 
The insurer's internal unique claim number; 
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The registration number of their insured's vehicle; 
The registration number of any other vehicle involved; 
The date of incident; 

The insurer's internal coding describing the type of incident; and 
5 An indication of the liability of the insurer. 

Whilst the content of some data items may still be unique, the format will now be 
identical, for example:- 

10 The insurer's internal unique claim number. 

In addition, the method, as part of this translation process, supplies an industry standard 
set of codes (ie. Relational Incident Codes) to describe information previously of an 
incompatible form to each insurer, for example:- 

15 

The insurer's internal coding describing the type of incident; and 
An indication of the liability of the insurer. 

When two vehicles are involved the paper flow increases to include the following steps:- 

20 

It is also part of the method's translation process that these common pieces of 
information are now readily shown to relate to the same incident, albeit from the 
perspective of the insurer of each vehicle according to the information reported to them 
by the owner of the vehicle. 

25 

The method has effectively converted information supplied by each insurer of different 
content and different format into the Essential Data now of identical format and identical 
content. 

30 Therefore, the method, now has in standard format as a result of this translation process, 
identical information in terms of content and format (provided that each piece of 
information was reported correctly by the owner of each vehicle to each insurer), for 
example:- 
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The registration number of their insured's vehicle; 

The registration number of any other vehicle involved; and 

The date of incident. 

5 Once this information has been translated by each insurer into the Essential Data 
according to the method's unique translation standards, the Information is randomly 
transmitted (in time) by each insurer to the central processing stage where it is randomly 
stored in the Database. 

10 In the Database is a Data Matching System that is now able to examine each data group 
as it is transmitted and stored, and compare each donated group to ones already stored 
in the system. 

In making this comparison, the method makes use of the fact that certain items within at 
1 5 least two of the Essential Data groups randomly may be identical in content and format, 
and that if it finds at least two such groups containing certain information which is 
identical in content and format, the method assumes that the Essential Data relate to the 
same motor vehicle incident. 

20 The matching of the Essential Data may contain the same information, now in the same 
content and format for certain items, for example:- 

The registration number of their insured's vehicle; 
The registration number of any other vehicle involved; and 
25 The date of incident. 

The method also makes use of the fact that previously incompatible data is now in 
common format and content to enable the method to effectively automatically decide on 
the likely outcome of any future litigation between each insurer as to liability for the 
30 motor vehicle incident, thus avoiding human interaction or legal involvement. 

The method utilises each insurer's own assessment of the incident to see if both agree, 
for example:- 
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Each insurer's internal coding describing the type of incident; and 
Each insurer's indication of the liability of the insurer. 

•- 

As these 'matching' Essential Data now represent each insurer's own assessment of the 
5 motor vehicle incident and fall into the method's unique set of Relational Incident Codes, 
the method system is now easily able to verify whether the Relational Incident Codes for 
the two matching groups Essential Data are compatible in that they indicate and clearly 
define the liability of each insurer. 

1 0 If there is a conflict between any of the information provided in each matching groups, 
each insurer is notified and they may make use of further use of the method as a means 
to transmit additional information to the other insurer by means of Standard ACORD 
Claim Forms and Inter-Company Advices. Presently a three character code suffices to 
resolve about half of the traffic incidents. A four character code may enlarge this 

1 5 proportion to three quarters 

However, where the information is not in conflict, then each insurer agrees that the 
method has automatically settled the liability aspect of the motor vehicle incident 
between the parties. 

20 

Stage 2 - Automatic Settlement (See Figure 4) 

Once liability has been settled by the method, that is a positive match has occurred, 
additional information as supplied by each insurer can be considered, for example:- 

25 

The cost of repairing their insured's vehicle. 

The method retains a set of parameters supplied by each insurer which allows the method 
to determine on behalf of each insurer the quantum of one insurer's claim against the 
30 other (as already established by the method in deciding liability through the matching of 
Essential Data). 

It is the perogative of the method-determined "At Fault" insurer to decide whether to 
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accept the quantum (ie. 'the cost of repairing their insured's vehicle*) supplied by the 
'Not at Fault' insurer according to the information held in their Essential Data, as the 'At 
Fault* insurer will be required by agreement and, ultimately, in law to reimburse the 'Not 
at Fault* insurer that quantum (ie. cost). 

5 

Therefore, the method will allow each insurer to set certain paraffieters within the coding 
of the method's programs which will allow the method to examine certain information 
supplied by both insurers, for example:- 

10 Each insurer's (translated) coding describing the type of incident; and 

The cost of repairing their insured's vehicle. 

In addition, the method may include additional information not previously described in 
the Essential Data to assist the 'At Fault' insurer in their assessment of whether to accept 
1 5 quantum, for example:- 

Insurer's (translated) coding describing the damage to their insured's vehicle; and 
A 'Total Loss Indicator'. 

20 The method is then able to consider this information from both insurers Essential Data 
and compare that information against the parameters set by prior instruction by the 'At 
Fault' insurer in order to make an automatic assessment on behalf of the 'At Fault' 
insurer as to whether they accept the 'Not at Fault' insurer's quantum; if accepted, the 
method has automatically settled the claim. 

25 

Alternatively, the 'At Fault* insurer, by prior setting of certain parameters within the 
coding of the method's programs, may elect to have the method refer (by way of 
transmission and translation back into the insurer's legacy system) the information 
supplied in the 'Not at Fault* insurer's data. 

30 

This will then enable the 'At Fault' insurer to make a personal assessment of the 
information supplied, which may include additional information, for example:- 
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Computer Scanned images of the damaged vehicle supporting the 'Not at Fault' 
insurer's quantum. 

Once the 'At Fault' insurer manually confirms their position relating to liability and 
5 accepts the 'Not at Fault' insurer's quantum, they may notify the method of this 
acceptance by the transmission of the method Acceptance Record at which point, our 
method is now also able to automatically settle the claim. 

The decision for the level of operator intervention required from Nil (ie. settle every 
10 claim) to 100% (ie. manually settle every claim) rests, in each case, with the 'At Fault' 
insurer and is set by prior agreement within our method who will adjust the program 
parameters to reflect each participating insurer's instructions as how they wish their 'At 
Fault' claims to be settled in regard to quantum. 

15 In most cases, the 'Not at Fault' insurer's claim in regard to quantum is settled entirely 
without human intervention. Human intervention merely adds data to enable the work 
flow to continue. 

In each case, each participating insurer's claim, regardless of 'At Fault' or 'Not at Fault' 
20 status, in regard to liability is settled through our method, with minimal human 
intervention. 

In all cases, the method only assumes a match (ie. a valid claim involving two 
participating insurers) if certain minimum sets of data within a minimum of two groups 
25 match in content and format, for example:- 

The registration number of their insured's vehicle; 

The registration number of any other vehicle involved; and 

The date of incident. 

30 

And, our method only proceeds to settlement, whether automatic settlement or manual 
settlement, if the Essential Data for each insurer match in relation to certain types of 
information allowing the method to make an assumption of acceptance of liability by 
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each of the participating insurers involved, for example:- 

Each insurer's internal coding describing the type of incident; and 
Each insurer's indication of the liability of the insurer. 

5 

Any other circumstance results in our Exception Report being Issued to all participating 
insurers whose Essential Data have achieved a match but cannot be settled in regard to 
either liability or quantum, and either automatically or manually settled. 

1 0 Finally, any Essential Data not achieving a match will result in an Exclusion Report 
being issued to the insurer who transmitted the data, whereupon the data may be deleted 
from the system by prior agreement with each participating insurer. 

Stage 3 - AutoBalance 

15 

It is expected that each participating insurer will submit and have settled by most of the 
claims within an appropriate period of time, expected to be measured in multiples of 1 
day. 

20 It is also expected that during each period of time, for each pair of participating insurers 
that there will be a multitude of incidents where each insurer assumes the role of either 
'At Fault' or 'Not at Fault' insurer. 

Therefore, there will be many instances within each period of time for each pair of 
25 participating insurers where a payment is made by either of the pair of participating 
insurers to the other. 

It is a further function of the system to calculate, at the end of each period of time, for 
each participating pair of insurers, the sum of each payment to be made to each insurer 
30 less the amount to be received from each insurer. 

Rather, than forward each payment to each insurer as they are automatically or manually 
settled, it is the function of the system to transfer to each insurer the balance of the 
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amount owing after the calculation of the sum of each payment to be made to each 
insurer less the amount to be received from each insurer, for each pair of participating 
insurers. 

5 It is expected that each insurer will maintain a Float (ie. a sum of money reasonably 
expected to cover the amount owning to each other participating insurer at the end of 
each period of time). The AutoBalance function is used to adjust the amount owing to 
each participating insurer by each other participating insurer. 

10 At the close of each period of time, the method and each participating insurer would 
transfer between them the required funds to maintain the Float; this may mean that 
additional funds are transmitted by the insurer to the system, or that the method transfers 
a surplus of funds held in excess of the method Float to the insurer (see Figure 4). 

15 The sum required to be maintained as the Float that is required for the AutoBalance 
function is expected to be far less than the amount that would otherwise be required by 
each participating insurer to accommodate the total amount of payments that would 
otherwise need to be made to each other insurer outside the system. 

20 Also, each participating insurer gains the immediate benefit (ie. at the close of each 
period of time) of the amounts deeded as owing according to the method from each other 
participating insurer. 

The sequence is shown in event stages in Figure 5. 

25 

We have found the advantages of the above examples to be:- 

( 1 ) Automated company to company advice; 

(2) More rapid payments leading to customer satisfaction and retention; and 
30 (3) Fraud detection by data mining. 

The claims, illustrations, photographs and drawings, if any, form part of the disclosure 
of this specification as does the description, claims, illustrations, photographs and 
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drawings of any associated provisional or parent specification or of any priority 
document, if any, all of which are imported hereinto as part of the record hereof. 

Finally it is to be understood that various alterations, modifications and/or additions may 
5 be incorporated into the various constructions and arrangements or parts without 
departing from the spirit and ambit of the invention. 
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THE CLAIMS DEFINING THE INVENTION ARE AS FOLLOWS:- 

1. A method of creating compatability of data exchange between multiple parties 
comprising:- 

utilising disparate data in disparate formats contributed"by the parties; 

placing the data in a common repository in order to permit automated treatment 
of the data between the parties. 

2. A data exchange method comprising admitting essential data donated by the 
parties to a common processing procedure, seeking matches in the essential data 
and notifying the parties of a match. 



15 3. An on line data exchange method for data donated by two or more parties 
comprising admitting essential data donated by the parties, converting the 
essential data of the parties to a common language and seeking a match between 
donated data. 

20 4. An on line data exchange method as claimed in Claim 3 wherein the essential 
data is legacy data from a donating party and is converted to common language 
by Extensible Mark Up language. 

5. An on line data exchange method as claimed in Claim 4 wherein the conversion 
25 is preceded by a screening step which checks for an omission in the essential 

data. 

6. An on line data exchange method as claimed in any one of Claims 3 to 5 wherein 
the establishment of a match causes notification to the relevant parties. 



30 



7. An on line data exchange method as claimed in Claim 6 wherein the notification 
is accompanied by provision of supplementary data to add a detail to the 
exchange. 
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An on line data exchange method as claimed in Claim 7 wherein the 
supplementary data includes the essential data from the donating parties. 

An on line data exchange method as claimed in Claim 7 or 8 wherein 
supplementary data includes a price. 

An on line data exchange method as claimed in any one of Claims 6 to 9 wherein 
the supplementary data is sent to the parties by the same channel used to collect 
the donated data. 

An on line data exchange method as claimed in any one of Claims 2 to 10 
wherein the notification of a match is followed by an operator's appraisal and a 
decision to transmit on the basis of the match and optionally the price. 

An on line data exchange method substantially as herein described. 

An on line insurance claim settling method comprising:- 

uploading essential data from parties who contributed data concerning the claim, 
converting the data to a mutually compatible form which enables the comparison, 
searching for a match in order to identify an incident common to two parties 
which is the subject of the claim. 

An on line insurance claim settling method as claimed in Claim 13 followed by 
notification of two parties concerned in the incident. 

An on line insurance claim settling method as claimed in Claim 13 or 14 wherein 
the essential data comprises the date of the incident, the registration number of 
a first vehicle; the registration number of a second vehicle, and the type of 
incident. 

An on line insurance claim settling method as claimed in any one of Claims 13 
to 1 5 wherein the type of incident is expressed in a compatible form wherever the 
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two parties refer to the same type of incident by a different code. 

17. An on line insurance claim settling method as claimed in any of Claims 1 3 to 15 
wherein any one party refers to an incident type by their code and another party 
refers to the same incident type by a different code, the codes are equated before 
a comparison is made. 

18. An on line insurance claim settling method as claimed in Claim 14 wherein 
notification is accompanied by the essential data. 

19. An on line insurance claim settling method as claimed in Claim 17 wherein the 
notification is accompanied by supplementary data which assists the parties in 
assessing their claim position. 



1 5 20. An on line insurance claim settling method as claimed in Claim 16 wherein the 
supplementary data includes a repair estimate from the party NOT AT FAULT 
for the party AT FAULT. 

21. An on line insurance claim settling method as claimed in Claim 19 wherein 
20 when a party accepts the estimate, the claim is notionally settled and a 

debit/credit adjustment is made between the accounts of the parties. 

22. An on line insurance claim settling method as claimed in Claim 20 wherein 
periodic transfers of money are made between the accounts of the parties to re- 

25 establish an agreed float quantum. 

23. An on line insurance claim settling method substantially as herein described. 

24. A data matching method for vehicle insurance claims comprising comparing data 
30 concerning vehicle incidents involving two vehicles, namely the registration 

numbers of the vehicles, the date of the incident and the individual claim numbers 
given by the insurers to the incident, and seeking a match in order to indicate that 
two sets of data refer to the same incident. 
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25. A data matching method as claimed in Claim 23 wherein the data includes the 
insurers category which classifies the type of incident. 
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Legacy data from insurers 



Data translatable? _ 



i — 

Make codes relational 
look for match. 



NO 

Supplement dictionary 



Match/No Match 



Report match to insurer 
Add background data 



Repair cost acceptable? 



Yes - Claim settled No - Negotiate. 



Float pays out 



Float replenished. Fig 5 
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